fix(llm): carry the schema in the prompt for minimax, and admit two terminal outcomes - #478

The OSS/enterprise boundary guard forbids vendor-specific references in
the OSS package, and this docstring named Sentry. The behaviour it
describes is unchanged; only the wording is.

…on_reason

The GEPA optimizer's failure path wrote `str(exc)` into
`playbook_optimization_jobs.decision_reason`. That column is durable, is
`TEXT NOT NULL` in both the SQLite and tenant Postgres schemas, is read
straight back into `PlaybookOptimizationJob`, and is shown to operators --
and an arbitrary exception message can carry customer content. A pydantic
`ValidationError` raised on a provider response renders the model's own
output (itself derived from evidence text) into its message; that was
confirmed on a sibling analysis path.

Every other writer of this column already uses a fixed phrase, so the
column is a de facto controlled vocabulary and this site was the outlier.
It now writes one too. Nothing diagnostic is lost: the `error_tags` block
immediately above already binds `error_type=type(exc).__name__` and
`logger.exception` records the traceback, which is where an unbounded
signal belongs.

The exception CLASS name is deliberately not added to the column either.
It is not customer content, but it would widen an operator-facing fixed
vocabulary into a semi-open one keyed on third-party exception types, and
it is already captured in the tags. This follows the precedent set by the
open-world terminal-failure diagnostic, which records class names under a
reserved metadata key while leaving the persisted reason vocabulary fixed.

Tests:
- a behavioural test raises an exception whose message carries a distinctive
  sentinel and asserts the sentinel reaches neither `decision_reason` nor
  `metadata_json`. Restoring `str(exc)`, and an f-string variant of it, both
  turn it red.
- an AST guard asserts every `decision_reason=` passed by a service-layer
  writer is a fixed string (or a conditional of fixed strings), so a new
  writer interpolating a value fails the build rather than leaking quietly.
  It carries a non-vacuity test that fails if the scan stops finding the
  known writers. It found a real false-positive class on its first run --
  the storage layer's row-to-entity hydration -- which is now excluded and
  documented.

The optimizer test harness gained `org_id` on its fake request context: the
exception path had never been exercised, so the missing attribute had gone
unnoticed.

…rmat

MiniMax ignores response_format through litellm. Measured against the live
API: two identical calls differing only in drop_params both returned free
prose rather than JSON, so the schema is discarded however it is sent.

The visible symptom was an analyst inventing a DIFFERENT set of field names on
every run - answering from the prompt alone, having never been given a schema.
With the schema in the prompt the same model returns exact conforming JSON.

Also normalize the schema in the prompt path before asserting provider safety,
mirroring the native json_schema path. Without that fold a discriminated union
would trip assert_provider_safe_schema and raise, so a prompt-only provider
could never carry one at all.

Splits one case out of `infrastructure_failure`: an open-world tuning attempt
that made NO provider call, because every durable row identity its discovery
question could occupy is already owned by a different optimization job.

The two were previously the same value, and that is what hid the defect they
describe. `offline_tuner_open_world_invocations` is keyed by
`analyst_input_identity` alone, derived without `job_id`, and attempt identity is
quantized to the UTC day -- so when a job died on the provider it left a
`prepared` row that pinned the question for the rest of that day, and every later
attempt died at prepare while reporting the same reason the original provider
fault reported. Distinguishing them required reading the invocations table by
hand.

Paired with the enterprise change that makes the collision recoverable
(`attempt_invocation_identity`), so this outcome is now the residue -- every
attempt identity owned -- rather than the common case.

The enterprise tenant CHECK is widened in the same change
(`supabase/data/tenant/20260903010000_open_world_invocation_slot_pinned.sql`),
and `test_the_enterprise_tree_agrees_with_the_contracted_oss_vocabulary` asserts
set equality between this Literal and that CHECK, so the two cannot drift.

510e492 added the 19th member of `OptimizationTerminalOutcome` but left this
guard asserting 18, so `test_the_union_is_exactly_the_reachable_set_plus_the
_retained_set` failed on the set-difference assertion with the new member extra
in the left set. That is the guard working as designed: its module docstring
says a member added to the union without a writer "lands in the reachable half
and fails the second test, which is the prompt to show that the new outcome can
actually be written." This answers the prompt.

The writer is real and named. `reflexio_ext open_world/runner.py:262-264` calls
`_converge_terminal_failure` with it from the
`OpenWorldInvocationSlotExhaustedError` arm -- ordered before its parent
`OpenWorldInvocationConflictError`, which would otherwise swallow it. The tenant
stage-advance RPC's 'failed' arm assigns it (20260903010000:129-131); the
'abstained' arm deliberately does not, because nothing was judged and there is
no decision artifact to write.

It is placed next to `regeneration_fenced` because the two are siblings: both
are open-world outcomes absent from the SQLite allowlist, so both must be named
here rather than left to the `writable <=` assertion to cover.

SQLITE AND THE OPTIMIZER MAP ARE CORRECTLY UNTOUCHED. The rationale recorded
for `regeneration_fenced` -- "SQLite carries no open-world fence" -- holds a
fortiori here: `grep` for `open_world_invocation`, `analyst_input_identity` and
`SlotExhausted` across `sqlite_storage/` returns nothing at all, so there is no
invocation table in which a slot could be pinned and no path that could write
the value. Both SQLite CHECKs (`_base.py:2292`, `:3537`) carry the same 17
values and omit `regeneration_fenced` and `invocation_slot_pinned` alike, which
is the consistent state, not a gap.

MUTATION EVIDENCE. Removing `"invocation_slot_pinned"` from the Literal while
keeping this change turns the guard red at the `members >= _REACHABLE` assertion
(1 failed, 2 passed), with the member reported extra in the right set. The
mutation was confirmed present in the file before running -- zero grep hits,
changed sha256, live `get_args` count of 18 -- and the file was restored by
rewrite from a backup copy and verified with `sha256sum -c` (OK), never with
`git checkout --`.

Verified: 3 passed in the guard, 546 passed across tests/models/, ruff check and
format clean, pyright 0 errors.